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Private Xx tensions to the Session Initiation Protocol (SXP) fox 
Assarted Identity within Trusted Setwork* 

Status of this Memo 

This memo provides information for the Internet community, it does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 

Copyright (C) The Internet Society (2002] . All Rights Reserved. 

Abstract 

This document describes private extensions to the Session Initiation 
Protocol (SIP) that enable a network of trusted SIP servers to assert 
the identity of authenticated users, and the application of existing 
privacy mechanisms to the identity problem. The use of these 
extensions is only applicable inside an administrative domain with 
previously agreed-upon policies for generation, transport and usage 
of such information. This document does KOT offer a general privacy 
or identity model suitable for use between different trust domains, * 
or use in the Internet at large. 
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1. applicability Statement 

This document describes private extensions to SIP (1] that enable a 
network of trusted SIP servers to assert the identity of end users or 
end systems, and to convey indications of end-user requested privacy. 
The use of these extensions is only applicable inside a 'Trust 
Domain ' as defined in Short term requirements for Network Asserted 
Identity [51 . Nodes in such a Trust Domain are explicitly trusted by 
its users and end-systems to publicly assert the identity of each 
party, and to be responsible for withholding that identity outside of 
the Trust Domain when privacy is requested. The means by which the 
network determines the identity to assert is outside the scope of 
this document (though it commonly entails some form of 
authentication) . 

A key requirement of [5] is that the behavior of all nodes within a 
given Trust Domain 'T 1 is known to comply to a certain set of 
specifications known as •Spec(T)*. Spec(T) MOST specify behavior for 
the following: 

1. The manner in which users are authenticated 

2. The mechanisms used to secure the communication among nodes within 
the Trust Domain 

3. The mechanisms used to secure the communication between OAs and 
nodes within the Trust Domain 
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4. The manner used to determine which hosts are part of the Trust 
Domain 

5. The default privacy handling when no Privacy header field is 
present 

6. That nodes in the Trust Domain are compliant to SIP [1] 

7. That nodes in the Trust Domain are compliant to this document 
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8. Privacy handling for identity as described in Section 7. 

An example of a suitable Spec(T) is shown in Section 11. 

This document does SOT offer a general privacy or identity model 
suitable for inter-domain use or use in the Internet at large. Its 
assumptions about the trust relationship between the user and the 
' network may not apply in many applications. For example, these 
extensions do not accommodate a model whereby end users can 
independently assert their identity by use of the extensions defined 
here. Furthermore, since the asserted identities axe not 
cryptographic*! ly certified, they are subject to forgery, replay, and 
falsification in any architecture that does not meet the requirements 
Of [5]. 

The asserted identities also lack an indication of who specifically 
is asserting the identity, and so it must be assumed that the Trust 
Domain is asserting the identity. Therefore, the information is only 
meaningful when securely received from a node known to be a member of 
the Trust Domain. 

Despite these limitations, there are sufficiently useful specialized 
deployments that meet the assumptions described above, and can accept 
the limitations that result, to warrant informational publication of 
this mechanism. An example deployment would be a closed network 
which emulates a traditional circuit switched telephone network. 

2. Conventions 

The key words "HOST", "KOST NOT", "REflDIRED", "SHALL", "SHALL NOT", 
■SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 13]. 

Throughout this document requirements for or references to proxy 
servers or proxy behavior apply similarly to other intermediaries 
within a Trust Domain {ex: B28UAs) . 
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The terms Identity, Network Asserted Identity and Trust Domain in 
this document have meanings as defined in [5] . 

3. Introduction 

various providers offering a telephony service over IB networks have 
selected SIP as a call establishment protocol. Their environments 
require a way for trusted network elements operated by the service 
providers (for example SIP proxy servers) to communicate the identity 
of the subscribers to such a service, yet also need to withhold this 
information from entities that are not trusted when necessary. Sucn 
networks typically assume some level of transitive trust amongst 
providers and the devices they operate. 



These networks need to support certain traditional telephony services 
and meet basic regulatory and public safety requirements. These 
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Include Calling Identity Delivery services, Calling identity Delivery 
Blocking, and the ability to trace the originator of a call. While 
baseline SIP can support each of these services independently, 
certain combinations cannot be supported without the extensions 
described in this document. For example, a caller that wants to 
maintain privacy and consequently provides limited information in the 
SIP From header field will not be identifiable by recipients of the 
call unless they rely on some other means to discover the identity of 
the caller. Masking identity information at the originating user 
agent will prevent certain services, e.g., call trace, rrom working 
in the Public Switched Telephooe Network (PSTN) or being performed at 
intermediaries not privy to the authenticated identity of the user. 

This document attempts to provide a network asserted identity service 
using a very limited, simple mechanism, based on requirements in (5]. 
This work is derived from a previous attempt, [6], to solve several 
problems related to privacy and identity in Trust Domains. A more 
comprehensive mechanism, [7) which uses cryptography to address this 
problem is the subject of current study by the SIP working group. 

Providing privacy in a sip network is more complicated than in the 
PSTN. In SIP networks, the participants in a session are typically 
able to exchange IP traffic directly without involving any SIP 
service provider. The IP addresses used for these sessions may 
themselves reveal private information. A general purpose mechanism 
for providing privacy in a SIP environment is discussed in [2). This 
document applies that privacy mechanism to the problem of network 
asserted Identity. 
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4. Overview 

The mechanism proposed in this document relies on a new header field 
called 'P-Asserted- Identity 1 that contains a OR I (commonly a SIP OrI) 
and an optional display-name, for example: 

F~Asserted-Identity: "Cullen Jennings" <sip: fluffyecisco.com> 

A proxy server. which handles a message can,, after authenticating the 
originating user in some way (for example: Digest authentication), 
insert such a P-Asserted- Identity header field into the message and 
forward it to other trusted proxies. A proxy that is about to 
forward a message to a proxy server or UA that it does not trust HOST 
remove all the P-Asserted-Identity header field values if the user 
requested that this information be kept private. Users can request 
this type of privacy as described in Section 7. 

The formal syntax for the P-Aaser ted- Identity header is presented in 
Section 9. 

5. Proxy Behavior 



A proxy in a Trust Domain can receive a message from a node that it 
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trusts, or a node that it does not trust. When a proxy receives a 
massage from a node it does not trust and it wishes to add a P- 
Asserted-ldentity header field, the proxy most authenticate the 
originator of the message, and use the identity which results from 
this authentication to insert a P-Asserted- Identity header field into 
the message. 

If the proxy receives a message (request or response) from a node 
that it trusts, it can use the information io the P-Asserted-Identity 
header field, if any, as if it had authenticated the user itself. 

If there is no P-Asserted-Identity header field present, a proxy KAY 
add one containing at most one SIP or SIPS DRI, and at most one tel 
URL. If the proxy received the message from an element that it does 
not trust and there is a P-Asserted-Identity header present which 
contains a SIP or SIPS CRT, the proxy MOST replace that SIP or SIPS 
URI with a single SIP or SIPS OKI or remove this header field. 
Similarly, if the proxy received the message from an element that it 
does not trust and there is a P-Asserted-Identity header present 
which contains a tel URI, the proxy MUST replace that tel URX with a 
single tel ORI or remove the header field. 

When a proxy forwards a message to another node, it must first 
determine if it trusts that node or not. If it trusts the node, the 
proxy does not remove any P-Asser ted -identity header fields that it 
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generated itself, or that it received from a trusted source. If it 
does not trust the element, then the proxy MUST examine the Privacy 
header field (if present) to determine if the user requested that 
asserted identity information be kept private. 

6. Hints for Multiple Identities 

ir a P-Preferred-Identity header field is present in the message that 
a proxy receives from an entity that it does not trust, the proxy may 
use this information as a hint suggesting which of multiple valid 
identities for the authenticated user should be asserted, if such a 
hint does not correspond to any valid identity known to the proxy for 
that user, the proxy can add a P-Asserted-Identity header of its own 
construction, or it can reject the request (for example, with a 403 
Forbidden). The proxy MOST remove the user-provided P-Pref erred- 
Identity header from any message it forwards. 

A user agent only sends a P-Pref erred- Identity header field to proxy 
servers in a Trust Domain; user agents MUST NOT populate the P- 
Preferred-Identity header field in a message that is not sent 
directly to a proxy that is trusted by the user agent. Mere a user 
agent to send a message containing a P-Pref erred- Identity header 
field to a node outside a Trust Domain, then the hinted identity 
might not be managed appropriately by the network, which could have 
negative ramifications for privacy. 

7. Requesting Privacy 

Parties who wish to request the removal of P-Asserted-ldentity header 
fields before they are transmitted to an element that is not trusted 
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may add the tt id n privacy token defined in this document to the 
Privacy header field. The Privacy header field is defined in [6). 
If this token is present, proxies MOST remove all the P-Asserted- 
Identity header fields before forwarding messages to elements that 
are not trusted. If the Privacy header field value is set to "none* 
then the proxy MUST ROT remove the P-Asserted-Identity header fields. 

When a proxy is forwarding the request to an element that is not 
trusted and there is no Privacy header field, the proxy MAY Include 
the P- Asserted- identity header field or it MAY remove it. This 
decision is a policy matter of the Trust Domain and MUST he specified 
in Speo(T). Zt is recommended that the P-Asscrted-Identity header 
fields SHOULD NOT be removed unless local privacy policies prevent 
it, because removal may cause services based on Asserted Identity to 
fail. 
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However, it should be noted that unless all users of the Trust Domain 
have access to appropriate privacy services, forwarding of the p- 
Asserted-Identity may result In disclosure of information which the 
user has not requested and cannot prevent. It is therefore STRONGLY 
RECOMMENDED that all users have access to privacy services as 
described in this document. 

Formal specification of the "id" Privacy header priv-value is 
described in Section 9.3. Some general guidelines for when users 
require privacy are given in 12] . 

If multiple P-Asserted- Identity header field values are present in a 
message, and privacy of the P- Asserted- Identity header field is 
requested, then all instances of the header field values MUST be 
removed before forwarding the request to an entity that is not 
trusted. 

8. user Agent server Behavior 

Typically, a user agent renders the value of a P-Asserted-Identity 
header field that it receives to its user. It may consider the 
identity provided by a Trust Domain to be privileged, or 
intrinsically more trustworthy than the From header field of a 
request. However, any specific behavior is specific to 
implementations or services. This document also does not mandate any 
user agent handling for multiple P-Asserted-Identity header field 
values that happen to appear in a message (such as a SIP URI 
alongside a tel URL) . 

However, if a User Agent server receives a message from a previous 
element that it does not trust, it must NOT use the P- Asserted- 
Identity header field in any way. 

If a DA is part of the Trust Domain from which it received a message 
containing a P-Asserted-Identity header field, then it can use the 
value freely but it MUST ensure that it does not forward the 
information to any element that is not part of the Trust Domain, if 
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the user has requested that asserted identity information be kept 
private. 

If a OA is not part of the Trust Domain from which it received a 
message containing a P-Asserted-Identity header field, then it can 
assume this information does not need to be kept private. 

9. Formal Syntax 

The following syntax specification uses the augmented Backus-Naur 
Form IBNF) as described in RFC-2234 [4 j . 
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9.1 She P-Asserted-Idaatity Header 

The P-Aseerted-Identity header field is used among trusted SIP 
entities {typically intermediaries) to carry the identity of the user 
sending a SIP message as it vas verified by authentication. 

PAasertedlD - "P-Asaerted-Ideatity M HCOLOM PAS serted ID- value 

* (COMMA PAssertedID- value) 
PAssertedXD-value - name-addr / addr-spec 

A P-Asserted- Identity header field value most consist of exactly one 
name-addr or addr-spec. There may be one or two P-Asserted-Identlty 
values. If there is one value, it MOST be a sip, sips, or tel ORI. 
If there are two values, one value MUST be a sip or sips ORI and the 
other MUST be a tel ORI. It is worth noting that proxies can (and 
will) add and remove this header field. 

This document adds the following entry to Table 2 of (1] : 

Header field where proxy ACK BYE CAN INV OPT BEG 

P-Asserted-Identity a or o - o o 



SOB HOT REP INF UPO PRA 
o o o - - - 

9.2 The P-Preferred-Identity Header 

The P-Preferred- Identity header field is used from a user agent to a 
trusted proxy to carry the identity the user sending the SIP message 
wishes to be used for the p-Asserted-Header field value that the 
trusted element will insert. 

PPreferredlD » "P-Preferred-Id entity" KCOLOer PPreferxedlD-value 

* (comma PPreferrediD-value) 
PPreferredlD-value - name-addr / addr-spec 

A P-Preferred-Identity header field value MOST consist of exactly one 
name-addr or addr-spec. There may be one or two P- Preferred-Identity 
values. If there is one value, it MOST be a sip, sips, or tel ORI. 
If there are two values, one value MOST be a sip or sips ORI end the 
other MOST be a tel ORI. It is worth noting that proxies can (and 



will) remove this header field. 
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This document adds the following entry to Table 2 of (1]: 

Header field where proxy ACK BYE CAN inv opt reg 



P-Preferred-Identity adr o - o o 

SUB NOT REF INF DPD PRA 
o o o 

9.3 The "id" Privacy Type 

Thia specification adds a new privacy .type ("priv- value") to the 
Privacy header, defined in [2]. The presence of thia privacy type in 
a Privacy header field indicates that the user would like the Network 
Asserted Identity to be kept private with respect to sip entities 
outside the Trust Donain with which the user authenticated. Note 
that a user requesting multiple types of privacy MUST include all of 
the requested privacy types in its Privacy header field value. 

priv-value ^ "id" 

Example ; 

Privacy: id 

10. Examples 

10.1 Network Asserted Identity passed to trusted gateway 

In this example, proxy. Cisco. com creates a P-Asserted-Identity header 
field from an identity it discovered from SIP Digest authentication. 
It forwards this information to a trusted proxy which forwards it to 
a trusted gateway. Note that these examples consist of partial SIP 
messages that illustrate only those headers relevant to the 
authenticated identity problem. 



* Fl uaeragent.cisco.com -> proxy.ci8CO.com 

INVITE eip;+14085551212!cisco.coin SIP/2.0 

Via: SIP/2.0 /TCP useragent.cisco.com?branch"z9hG4bK-123 

To: <slp:+140a , S5512126cisco.con> 

From: "Anonymous*' <sip:anonymous8anonymou3. invalids tag=98027 48 
Call-ID: 245780247857024504 
CSeq: 1 INVITE 
Max- Forwards: 70 
Privacy: id 
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* F2 proxy.cisco.com -> useragent.cisco.com 
SIP/2.0 407 Proxy Authori2ation 

Via: SIP/2. O/TCP userag ent.cieco.com; bra nch°2&hG4bK-L23 
To; <sip:fl408SS51212ecisco.com>;tag»l23456 

From: "Anonymous" <sip : anonymous Sanonyruo us. invalid>;tag«9 8 027 43 
Call-ID: 245780247857024504 
CSeq: 1 INVITE 

proxy-Authenticate; .... realms" sip. Cisco. com" 

* F3 useragent.clsco.com -> proxy.cisco.com 

INVITE sip: +14085551212 gcisco.com SIP/2. 0 

Via; SIP/2. O/TCP useragent .Cisco .com; branch-i9hG4bK-124 

To: <sip:+140855512126cisco.com> 

From: "Anonymous" <sip:anonymous8anonymou3.invalid>;tag»9B02748 
Call-ID: 245760247857024504 
CSeq: 2 INVITE 
Max- Forwards: 70 
Privacy: Id 

Proxy-Authorisation: .... re*lffi-"8ip. Cisco. com" user«"f luf fy" 

* F4 proxy.cisco.com -> proxy.pstn.net (trusted) 

INVITE sip:+14085551212eproxy.pstn.net SIP/2. 0 
Via: SIP/2. O/TCP useragent.casco.com;branch«z9hG4bK-124 
via: SIP/2. O/TCP proxy. Cisco. com; bra nch«r 9 hG4bK-abc 
To: <sip:+14085551212ecisco.com> 

From: "Anonymous" <sip:anonymous8anonymous.invalid>; tag»9802746 
Call-ID: 245780247857024504 
CSeq: 2 INVITE 
Max-Forwards: 69 

P-Asserted-Identity: "Cullen Jennings" <sip: flutfy8cisco.com> 
P-Asserted- Identity: tel:+14085264000 
Privacy: id 
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* F5 proxy.pstn.net -> gw -pstn.net (trusted) 
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INVITE sip: +14085551212egw. pstn.net SIP/2.0 
Via: SIP/2. O/TCP useragent.ciaco.com:branch«z9hG4bK-124 
Via: SIP/2. 0 /TCP proxy. cisco. com; branch 3 z9hS4bK-abc 
via: SIP/2. 0/TCP proxy. ps tn.net; bra nch»z9hG4bK-alb2 
To: <sip: +140855512 128cisco.com> 

From: "Anonymous" <sip: anonymous 6anonymous . invalid>;tag-980274B 
Call-ID: 245780247857024504 
CSeq: 2 INVITE 
Max -Forwards: 68 

P- Asserted- Id entity: "Cullen Jennings" <sip: fluffyecisco.com> . 
P-Asserted-Identity: tel: +1408 5264000 
Privacy: id 

10.2 B»tw*rk Assort** Identity Hithneld 

In this example, the Osoi Agent sends an INVITE that indicates it 
would prefer the identity sip: fluffy@cisco.com to the first proxy, 
which authenticates this with SIP Digest. The first proxy creates a 
P-Asserted-Identity header field and forwards it to a trusted proxy 
{outbound.cisco.com). The next proxy removes the P-Asserted-Identity 
header field and the request for Privacy before forwarding this 
request onward to the biloxi.com proxy server which it does not 
trust. 

* Fl useragcnt.cisco.com -> proxy.cisco.com 
INVITE sip: bobflbiloxi.com SIP/2.0 

Via: SIP/2. O/TCP useragent. cisco. com; bra nch-z9hG4bK-a 111 
To: <sip j bob@biloxi.com> 

From: "Anonymous" <sip:an©nvmouseanonymoiis.invalid>;tag' B 9802748 
Call-ID: 245780247857024504 
CSeq: 1 INVITE 
Max-Forwards: 70 
Privacy: id 

P-Pref erred- Identity: "Cullen Jennings" <sip:fluffy8cisco.com> 

* F2 proxy.cisco.com -> useragent.clsco.com 
SIP/2. 0 407 Proxy Authorization 

Via: SIP/2. O/TCP useragent. cisco. com;branch=z9hG4bK-alll 
To: <sip: bob8biloxi.com>; tag- 1234 5 6 

From: "Anonymous" <sip:anonymoua$anonymous.invalid>jtag-9802748 
Call-ID: 245780247857024504 
CSeq: 1 INVITE 

proxy-Authenticate: .... realm- "Cisco. com" 
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* F3 useragent.clsco.com -> proxy.cisco.com 
INVITE sip: bob8biloxi.com 8IP/2.0 

Via: sip/2 , O/TCP useragent. cisco. com; branch«z9hG4bK-al 2 3 
To: <slp: bobeblloxi.com> 

From: "Anonymous" <slp:anonymous6enonymou6.invalid>;tag-9802748 
Call-IDs 245780247857024504 
CSeq: 2 INVITE 
Max-Forwards : 70 
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Privacy: id 

P-Pteferred-Identity: "Cullen Jennings 0 <5ip: flufCy6ci8co.com> 
Proxy-Authoriiation: .... reain- ,, cisco.coci" user** -fluffy" 

* P4 proxy.cisco.com -> outbound.cisco.com (trusted) 
INVITE siprbobebiloxi SIP/2.0 

Via: SIP/2. O/TCP user agent. cisco.com; branch*=z9hG4bK-al2 3 
Via: SIP/2. O/TCP proxy. cisco. com; branch«z9hG4bK-b2 34 
To: <8ipibobebiloxi.com> 

From: •Anonymous" <s ip: anonymous Ganonymous.invalid>; tag-9802748 
Call-ID: 245780247857024S04 
CSeq; 2 INVITE 
Max- Forwards: 69 

P-Asserted-Identity: "Cullen Jennings" <sip: fluffy@vovida.org> 
Privacy: id 

* F5 outbound.cisco.com -> proxy.biloxi.com (not trusted) 
INVITE sip:bobfibiloxi SIP/2.0 

Via i SIP/2. O/TCP useragent. cisco. com; branch-z9hG4bK-al23 
Via: SIP/2. O/TCP proxy. cisco. com;branch s z9hG4bK-b234 
Via: SIP/2. O/TCP outbound. cisco.com/branch-z9hG4bK-c345 
To: <sip: bob@biloxi.com> 

From: "Anonymous 0 <Bip:enonymous&anonyim>us.invalid>;tag=9802748 
Call-ID: 245780247857024504 
CSeq: 2 INVITE 
Max- Forwards: 68 
Privacy : id 
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♦ F6 proxy.biloxi.com -> bobster . biloxi . com 

INVITE sip: bob8bobster.biloxi.com SIP/2.0 
Via: SIP/2. O/TCP useragent. cisco. com; branch- z9hG4bK-al23 
Via: SIP/2. O/TCP proxy. Cisco. com ; branch- z9b64bK-b23 4 
Via: SIP/2 , O/TCP outbound. cisco. com;branch-z9hG4bK-c345 
Via: SIP/2. O/TCP proxy,biloxi.com^bcanch-z9hG4bK-d456 
to: <sip:bob8biloxl.com> 

From: "Anonymous 11 <8ip:anony»ous8anonyiaous.invand>;tag=9802748 
Call-ID: 24S780247857024S04 
CSeq: 2 INVITE 
Max-Forwards: 67 
Privacy: id 



11. Kxampl* of Spec(T) 
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The integrity of the mechanism described in this document relies on 
one node knowing (through con figuration) that all of the nodes in a 
Trust Domain will behave in a predetermined way. This requires the 
predetermined behavior to be clearly defined and ror all nodes in the 
Trust Domain to be compliant. 7be specification set that all nodes 
in a Trust Domain T must comply with is teemed 'SpectT} 1 . 

The remainder of this section presents an example Spec<T), which is 
not normative in any way. 

1. Protocol requirements 

The following specifications MOST be supported: 

1. RFC 3261 

2. RFC 3325 

2. Authentication requirements 

Users MUST be authenticated using SIP Digest Authentication. 

3. Security requirements 

Connections between nodes within the Trust Domain and between 
UAs and nodes in the Trust Domain HOST use TLS using a cipher 
suite Of RSAJJITH_ABS_128_CBC_SHAl. Mutual authentication 
between nodes in the trust domain MUST be performed and 
confidentiality MUST be negotiated. 
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4. Scope of Trust Domain 

The Trust Domain specified in this agreement consists of hosts 
which posses a valid certificate which is a) signed by 
ezamplerootca.org; b) whose subjectAltKame ends with one of the 
following domain names; trusted.divl.carrier-a.net, 
tru3ted.div2.carrier-a.net, sip. carrier-b.com/ and c) whose 
domain name corresponds to the hostname in the subjectAltName 
in the certificate. 

.5. implicit handling when no Privacy header is present 

The elements in the trust domain must support the 'id' privacy 
service therefore absence of a Privacy header can be assumed to 
indicate that the user is not requesting any privacy. If no 
Privacy header field is present in a request, elements in this 
Trust Domain MUST act as if no privacy is requested. 

12. Security Considerations 



The mechanism provided in this document is a partial consideration of 
the problem of identity and privacy in SIP. For example, these 
mechanisms provide no means by which end users can securely share 



identity information end-to-end without a trusted service provider, 
identity information that the user designates as 'private' can be 
inspected by any intermediaries participating in the Trust Domain. 
This information is secured by transitive trust, which is only as 
reliable as the weakest link in the chain of trust. 

When a trusted entity sends a message to any destination with that 
party's identity in a P-Asserted- Identity header field, the entity 
MOST take precautions to protect the identity information from 
eavesdropping and Interception to protect the confidentiality' and 
integrity of that identity information. The use of transport or 
network layer hap-by-hop security mechanisns, such as TLS or IPSec 
with appropriate cipher suites, can satisfy this requirement. 

13 . XUOL Considerations 

13.1 Registration of new SZF header fields 

This document defines two new private SIP header fields, "P- 
Asserted-Identity" and "P-Pref erred- Identity". As recommended by the 
policy of the Transport Area, these headers have been registered by 
the XANA in the SIP header registry, using the RFC number of this 
document as its reference. 
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Name of Header: P-Aaserted-Identity 

Short form: none 

Registrant: Cullen Jennings 

f luf fyecisco . com 

Normative description: 
Section 9.1 of this document 

Name of Reader: ?- Prefer red- identity 

Short form: none 

Registrant: Cullen Jennings 

f luf f y 8 Cisco. com 

Normative description: 
Section 9.2 of this document 

13.2 Registration of "id" privacy type for SIP Privacy header 

Name of privacy type: id 

short Description: Privacy requested for Third- Party Asserted 

Identity 

Registrant: Cullen Jennings 

fluffyecisco.com 
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Normative description: 
Section 9.3 of this document 
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